zpcprovider for sign/verify (ecdsa/eddsa)#41
Conversation
|
Are you looking at the Travis build failures? You might need to build OpenSSL from source to have a 3.5.0 version to build against. |
|
Yes, a fix for the travis is in progress. It looks like travis only provides 3.0 out of the box. So I'll build my own. At least 3.5, better 4.0. |
holger-dengler
force-pushed
the
provider-sign
branch
2 times, most recently
from
7c72889 to
1659e06
Compare
|
The update contains:
|
holger-dengler
force-pushed
the
provider-sign
branch
from
9258c6f to
6d1b3d8
Compare
|
Another update (force push) to remove the merge conflicts and add a fix for travis. |
|
I would suggest to also add tests that utilize the openssl application to use protected key origins. For example, creating/signing a certificate with a protected key origin specified via URI or PEM using |
I plan to rework the test. |
|
I would move the provider sources into a subdirectory, e.g. |
|
I would postpone the source code restructuring until the provider transition is done (symmetric cipher, secure-key origins etc). There will be eventually also some removal of no longer used code. |
holger-dengler
force-pushed
the
provider-sign
branch
from
6d1b3d8 to
690f619
Compare
The mapping helpers provide mappings between e.g. algorithm strings and algorithm-related values. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Introduce a store-loader for hbkzpc-URI based keys. The store-loader creates a provider-specific key object and adds relevant information from the URI. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Introduce a asymmetric key management to map the provider-specific key object to a intern zpc-key. Not supported: - key generation - key import Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Add helpers to generate DER-encoded algorithm-ids based on key and digest information. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Add signature algorithms for sign/verify with ECDSA and EDDSA keys. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Add the supported TLS properties for the zpcprovider. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
The ASN.1 module provides DER en-/decoding for hbkzpc-URIs. These functions are required for the decoder/encoder support. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Add internal object build target for ASN.1 module. The internal object can be shared between targets. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Add decoders for PEM and DER to support hbkzpc-URI files. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
To use the zpc functionality via the OpenSSL API, the zpcprovider has to be defined in the OpenSSL configuration. The build configures the template and creates a `openssl.cnf` file, which can be used for test purposes. The configuration file will be created in the build output folder. The build also configures a second template and creates a configuration drop-in file `zpcprovider.cnf`. This file can be included in existing OpenSSL configuration files. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
The scripts set breakpoints for to all zpcprovider functions, which are called by the OpenSSL provider API (dispatch functions). Each zpcprovider component has its own gdb-script. Sourcing multiple scripts is possible. Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
holger-dengler
force-pushed
the
provider-sign
branch
from
d281dfe to
befe371
Compare
|
The current PR version contains a lot of fixes. The tests with the hard-coded keys (t_provider) has been removed completely. For testing purposes, I would suggest to checkout PR #43, as it provides test scripts which uses openssl cli to trigger the zpcprovider. Further improvements:
|
| - cmake -DBUILD_TEST=ON .. 2> >(tee) | ||
| - make 2> >(tee) | ||
| - cmake -B build -S . -DCMAKE_INCLUDE_PATH=${OPENSSL_DIR} -DCMAKE_LIBRARY_PATH=${OPENSSL_DIR} 2> >(tee) | ||
| - cmake --build build --target zpc 2> >(tee) |
There was a problem hiding this comment.
Would it be possible to also run some tests here? Probably not .....
There was a problem hiding this comment.
All current tests require at least some existing key files. Provider tests in addition require a sel-setup. I would like to postpone futher testing to upcoming releases.
| zpcprovider, use the absolute or relative path to the installation | ||
| location of `zpcprovider.so`. | ||
|
|
||
| identity (optional) |
There was a problem hiding this comment.
Are you anywhere describing the URI format?
I always wondered why the URI has hbkzpc: but we otherwise always talk about the zpc provider (no hbk here).
In the example OpenSSL conf file you have identity = hbkzpc. One could wonder why?
Also you register the provider operations with a hard coded provider=hbpzpc property string. What happens if one uses a different identity in the config ? Shouldn't the operations registration follow the identity string?
Or maybe just define that it must be identity = hbkzpc.
There was a problem hiding this comment.
I'll add the description of the URI format to the zpcprovier.7 man page. I think, that would be the right place as this man page covers all conceptual topics.
There was a problem hiding this comment.
Right.
And please consider dropping the identity = hbkzpc thing completely.
With an identity set to blah, one would expect that your provider could be fetched with a property query like provider=blah- However, this does not work with your provider, since you register the operations hard coded with provider=hbpzpc regardless of the specified identity....
I don't see why you would want to allow anyone to specify a different identity at all. It would make sense if one could define multiple instances of the same provider with different settings. Then each would need its own identity to be able to fetch them separately. Your provider does not have any settings, so having multiple instances of it just does not make any sense.
The IBMCA provider allows multiple instances with different settings and different identities, and it registers the operations with the specified identity (See https://github.com/opencryptoki/openssl-ibmca/blob/7292da59025c5ca487da148c47be44d895708a1e/src/provider/p_ibmca.c#L1316 and https://github.com/opencryptoki/openssl-ibmca/blob/7292da59025c5ca487da148c47be44d895708a1e/src/provider/p_ibmca.c#L1196). I don't think that this complexity is needed for the zpc provider. Neither the default nor the base provider allow a different identity either.
There was a problem hiding this comment.
Regarding your other questions:
- zpc vs. hbkzpc:
hbkis the abbreviation for the generic concept (hardware-backed key), whilezpcis the abbreviation for platform specific implementation of this concept. I pickedhbkzpcfor the URI protocol, to express that the URI is targeting the generic concept, as well as the concret implementations. - I picked
zpcproviderfor the provider name andzpcprovider.sofor the module, because it is the concrete implementation. - AFAIK there is no way, that the provider registration can follow the identity string. I've not seen such handling in other provider.
There was a problem hiding this comment.
AFAIK there is no way, that the provider registration can follow the identity string. I've not seen such handling in other provider.
Right, so just drop the identity = hbkzpc from the config example, snippets, and man pages.
There was a problem hiding this comment.
Should I mention in the man pages, that setting the identity is not supported?
There was a problem hiding this comment.
Probably yes. Something like if the identity is set to something other than hbkzpc then is has no effect....
You can't really hinder anyone from setting the identity (well you could check in the code if its the expected identity and fail otherwise.... but do we really want to do this?)
There was a problem hiding this comment.
As the zpcprovider has no further configuration possibility, it does not make any sense at the moment, to have multiple instances of it configured at the same time. And if there is only a single instance, it does not make any sense to specify the identity.
So, for the moment, setting the instance is not supported. It might change in the future, but not yet. I'll mention this in the configuration man page.
There was a problem hiding this comment.
I'll do the following global renaming:
- zpcprovider --> hbkzpc provider: all occurrences of the provider name
- zpcprovider.7 --> hbkzpcprovider.7: name of the man page
- zpchbk --> hbkzpc: all ASN1 objects will be changed
- zpchbk --> hbkzpc: the DER structure will be change.
- "ZPC HARDWARE BACKED KEY" --> "HARDWARE BACKED KEY ZPC": PEM URI string will be changed (*)
The following names will stay unchanged.
- zpcprovier.so: the module name will not be changed
- hbkzpc: the URI protocol will not be changed.
- hbkzpc: the internal provider identity will not be changed.
Any concerns or counter-proposals?
(*) this requires a re-generation of all local PEM/DER files for testing!!!
2 participants
This PR requires PR #40.
This PR adds OpenSSL provider support for libzpc. This first version covers the main functionality for store, keymgmt, sign/verify and decoder support.
As the series add a lot of new code, it is split into many commits to make the review (hopefully) a bit easier.
ToDo:
Restriction:
tprovider.c.